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Abstract —Blockchain as a distributed data structure or ledger 
is perceived to provide solutions in manifold areas beyond their 
prominent form of digital currency; they also showed several 
challenges. As enhancements to the existing blockchain systems 
are being proposed and developed, alternative underlying data 
structures were driven to solve some of the challenges facing 
them whilst maintaining their key ideas. We start by explaining 
the key concepts of the blockchain as implemented in Bitcoin 
and Ethereum. From there, we explain the challenges and survey 
on the alternative data structures along with their consensus 
mechanisms. We find a generalization in using hash pointers in 
the alternative data structures and unfold the current research 
and implementation directions for solutions to the challenges. 
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I. Introduction 

Blockchain as a data structure was first perceived upon 
Satoshi Nakamoto’s proposal for Bitcoin [1] as an electronic 
currency. Although multiple forms of digital cash were dis¬ 
cussed and implemented before it, Bitcoin brought the tech¬ 
niques together and provided an implementation that elim¬ 
inates the need for intermediaries or trusted third parties, 
providing a decentralized consensus algorithm. Before Bitcoin, 
B-money was proposed in [2] and Bit-gold in [3]. The very first 
implementation, DigiCash [4], was based on Chaum’s blind 
signatures [5]. As a peer-to-peer open ledger, Bitcoin provided 
an idea for decentralizing trust. As the core data structure, 
blockchain provided means to store data in a cryptographically 
secure and transparent manner that is computationally hard to 
tamper with. The protocol, proof-of-work (PoW), an extended 
version of Hashcash [6], provided the network with consensus 
upon the globally accepted data structure. Directed acyclic 
graph (DAG) is also used as a distributed data structure to form 
ledgers. With different topologies, it is becoming increasingly 
used as a blockchain alternative. We survey such topologies 
and briefly elaborate on the mechanisms chosen to achieve 
distributed consensus over each of them. 

This survey starts with an introduction to Blockchain 
and its key features, distributed consensus and how it is 
achieved, followed by the key concepts behind two of the 
most known implementations, Bitcoin and Ethereum [7], [8]. 
Afterwards, we focus on the challenges facing blockchain 
systems, and the directions taken to solve them. Each of the 


DAG implementations we consider has its unique properties. 
A) The block-lattice structure as implemented in the project 
Nano (previously known as Raiblocks) [9], B) Hashgraph [10] 
data structure, and C) the Tangle [11] data structure and its 
implementation in the project IOTA. We chose these structures 
as they propose unique approaches aimed to solve challenges 
that are not yet solved by blockchain variations. 

Although there is an explosion in the projects that start 
from bitcoin code base or its light version Litecoin [12], 
some of them focus on solving one of the challenges, and 
others provide specific modifications to test potential Bitcoin 
features. For a detailed and exemplified explanation of the key 
elements of Bitcoin that we mention briefly for the purpose of 
our survey, we refer to other surveys [13], [14]. The closest 
paper to this one [15] offers a comparison between blockchain 
presented in Bitcoin and Ethereum, and DAGs presented in 
Nano. We extend the alternatives to include two more unique 
DAG structures, namely Hashgraph and the Tangle. Further, 
we start by the blockchain challenges that led to the alternative 
structures and highlight the research and solution paths taken 
towards solving them. It is important to note that some of 
subjects discussed here present proposals or implementations 
that may have not found its way to be described with scientific 
rigor. However, we include their references for a complete 
picture on the matter we survey. 


II. Distributed Ledgers 

Distributed ledger technology (DLT) store data or transac¬ 
tions in a shared form. As a state machine, the ledger has a 
certain state and a transaction set represents the change from 
one state to another. A new state requires to be agreed upon 
by the participants. As a ledger is presented by its underlying 
data structure, a consensus protocol is used to reach distributed 
agreement. There are two categories of distributed ledgers, 
open or permissionless, and private or permissioned. We 
generally note that open ledgers may have further requirements 
than those for other distributed systems. Typically, they require 
an incentive mechanism to get members to participate in the 
network. Also, the identity of participants is not persistent for 
long periods, as nodes can join and leave the network freely. 
We note that the structures we consider are all, at the time of 
writing, open ledgers. 
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Fig. 1. Typical blockchain structure. 

A. Blockchain Structure 

Blockchain is a chain of blocks ordered using crypto¬ 
graphic hash pointers as unique identifiers, see Figure 1. Each 
block contains some data as well as a hash pointer to its 
previous block. The hash pointer is a key that references 
the previous block storage, and a timestamped hash of the 
data of that block, used to verify its integrity. Hash pointers 
provide blockchains with a tamper-evident structure and a 
claim to immutability. While blockchains are not tamper-proof 
by nature, it is cryptographically verifiable that the blocks 
maintain the same data as they were initially created. The 
integrity of the data in the blocks is reliant on the cryptographic 
hash function being used and is primarily subject to the 
security features of such function. The first block, referred to 
as the genesis block, is mostly hard-coded for reference values. 

1) Blocks forming a Blockchain: Blocks typically contain 
headers and data. The header hash is referred to as the block 
hash. A block header contains metadata as the previous block 
hash, a nonce value, the root hash of a Merkle tree, and a 
timestamp. The data, or the Merkle tree itself, is included in 
the body. Block height refers to the number of blocks from 
genesis block to a certain block. 

2) Merkle Trees: The block body or data can be further 
arranged to contain other data structures. One common data 
structure used in Bitcoin and Ethereum is the Merkle Tree, or 
its variant the Merkle Patricia Tree, in which the leaf nodes 
represent data blocks and the non-leaf nodes are the hashes of 
their children nodes [15]. Such trees include transaction sets. 
For a logarithmic performance, they are usually implemented 
as binary trees. The data blocks can be validated against the 
tree root for tampering. A change in one leaf node requires 
the subsequent parent nodes to change, changing the root itself. 
Thus, if the root is known, the whole tree can be communicated 
in pieces from different sources. As the hashes propagate 
upwards, the tree can be validated partially without its whole 
structure. 

III. Distributed Consensus 

A distributed data structure would often require means by 
which the its participants reach an agreement on the state of 
its data. This is studied in distributed consensus algorithms. 
The problem boils down to the Byzantine Generals Problem 
(PGB) [16]. Byzantine Fault Tolerance (BFT) is often a desired 


distributed system property. There are two usages to the 
term BFT. Weak BFT assumes that the communication is 
weakly asynchronous and attackers will not collude [17]. This 
assumption does not hold in open ledger networks. In the 
stronger definition, up to 1/3 of the participants’ collusion is 
tolerated. With strong asynchrony for the BGP, it is proved [18] 
that every system has the possibility of non-termination if one 
process is faulty, and thus it is impossible for such system to 
reach consensus. In practice, this means that the requirements 
for such system to exist are not absolute and have to be less 
stringent to guarantee a probabilistic or a heuristic termina¬ 
tion. Protocols as Paxos, PBFT [17], and Raft [19] provide 
early solutions to the problem. Bitcoin solves the consensus 
nondeterministically by using PoW, and hence the byzantine 
property can be denied. Instead, a probabilistic confidence rate 
increases with time that the chain under consent cannot be 
changed. It is assumed that the messages are not tampered 
with if the underlying cryptographic guarantees hold. 

Other PoW alternatives, such as Proof-of-Stake (PoS) and 
its variants, are proposed, and some of which are implemented 
[8], [14], [20]-[22]. Generally, the term proof-of-x is used 
to refer to a cryptographically verifiable way to proof an 
unknown. 

IV. Bitcoin 

Bitcoin is a peer-to-peer, arguably decentralized [23], net¬ 
work that uses blockchain as an open ledger for storing 
transactional data. It uses digital signatures to sign the transac¬ 
tions, along with a PoW algorithm to both, achieve distributed 
consensus on the blocks between the peers, and solve the 
double-spending attacks by validating every transaction by 
the entire network. Sybil attacks [24] are also neutralized by 
assuming that computational power majority is more reliable 
than forged identities. Distributed consensus on the chain itself 
is assured using a rule to follow the longest valid chain, which 
represents a maximization of the computation power known as 
the hash rate of the network. 

PoW is a process of finding a hash value that begins with 
a certain difficulty. This is determined by a predefined number 
of leading zero bits that is dynamically adjusted to keep the 
block generation at an average number of blocks per hour. The 
time required to find such hash is exponential in the difficulty 
but also verifiable using a single hash function execution. The 
nonce value in the block header is brute-forced to find such 
hash value. In Bitcoin, the hash function h(x) is evaluated 
twice for PoW and transaction hashes [25], that is h(x) = 
SHA-256(SHA-256(x)). 

Bitcoins are stored in digital wallet addresses. Using public 
key cryptography, a private-public key pair is generated first. 
The public key is hashed multiple times in order to generate 
an address. Bitcoin currently uses ECDSA parametrized by the 
secp256kl curve for key generation. It then uses SHA-256 and 
RIPEMD-160 subsequently to hash the public key. A version 
number is prepended, and a checksum is appended. The result 
is base58-encoded to generate the final address [14]. Base58 is 
used to remove ambiguity in reading characters. This process is 
recommended but not enforced. The notion of Bitcoin storage 
is abstract in that the chain of transactions represent the balance 
of a Bitcoin address, but there is no actual equivalent of coins. 




As previously mentioned, transactions are logged into the 
Merkle tree and represented in the block header as its root. 
Generally, a transaction is created by digitally signing the hash 
of the previous transaction along with the public key or address 
of the next owner using the previous owner’s private key. The 
signatures are verified to validate the chain of ownership. One 
transaction can have multiple inputs to spend, and multiple 
outputs. Each input represents a previous transaction, an index 
to its output to spend, and a signature script. The script 
contains an ECDSA signature and the public key of the signer 
to be used for verification. All input values must be dedicated 
to output addresses and the remaining value is considered a 
transaction fee. Each output contains the value of Bitcoin in 
satoshis, where each Bitcoin contains one million satoshis, 
and a public key script. Scripting provides some degree of 
programmability allowing multi-signatures and other contract 
forms and providing some transaction flexibility in a simple 
stack-based language. Transaction outputs that are spendable 
by other transactions are called Unspent Transaction Outputs 
(UTXOs), they form the balance or coins in an address. Each 
UTXO can be spent once. The transaction that provides a block 
reward has no inputs. It is called the coinbase transaction. It 
can only be spent after adding 100 subsequent blocks to the 
blockchain. Individual transactions can be verified by tracing 
their ancestor parents. This will eventually terminate at either 
a coinbase transaction, or the genesis block. 

The peers involved in the PoW process, or the miners, com¬ 
pete to find the next block for a reward of certain decreasing 
number of Bitcoins, started at 50 and currently at 12.5. Every 
210,000 blocks, the mining reward halves. Rewards, however, 
provide an incentive to join the network. Miners compute the 
PoW value to find a block. To claim the reward, a coinbase 
transaction of the same value is created and added to the 
transaction set. Miners are also incentivized by transaction fees 
that are optional. For game theoretic reasons, the transactions 
with higher fees are picked first. When the circulation limit 
is reached, which is slightly less than 21 millions, no rewards 
are given, and the only incentive is the transaction fees. 

A full-node in Bitcoin stores all the blocks and processes 
them. As the blockchain size grows, the light nodes are used in 
a Simplified Payment Protocol (SPV) that is based on Merkle 
trees. It stores the block headers and only the branches of 
Merkle trees which are associated with transactions to be 
validated, making it a space-effective solution. 

Y. Ethereum 

The Ethereum project provides Turing-complete pro¬ 
grammable contracts, referred to as Smart Contracts (SCs) over 
a blockchain architecture. The term is coined by Nick Szabo 
[26], [27]. SCs entitle two or more participants communica¬ 
tion, allowing decentralized applications encoding their own 
arbitrary state transition functions to exist over the blockchain 
network. Ether is the main currency or token. In contrast with 
the UTXO model, Ethereum uses an account-based model. 
The accounts are of two types, externally owned and contract 
accounts. The first has no code, while the second maintains 
a code that is activated when it receives a message so that 
it sends other messages or create contracts. Contracts behave 
as autonomous agents that live in the Ethereum Execution 
Environment (EVM). They have their own key/value store and 


Ether balance. Transactions are the form data that is sent to 
externally owned accounts, and messages are data sent between 
contracts. Computation steps have a unit of payment called gas. 
The gas is used as a price for each computation step at one gas. 
Some steps require higher gas according to their computational 
expense. The gas limit determines the maximum amount of 
gas a block can consume for all its transactions. Transactions 
contain a property to maintain a dynamic value for the gas 
price in Ethers. Every byte in transaction data requires 5 gas. 
The fees on computation, resources, and bandwidth serve as 
an anti-denial of service technique [7]. 

Block production time in the Ethereum network is 14-26 
seconds, while in Bitcoin it is 10 minutes, on average. As the 
GHOST modification proposers explain [28], the blockchains 
with fast production time are less secure because of high stale 
rate. The stale rate represents blocks that are produced after 
another one that is not yet propagated or delayed. When a 
network reaches consensus, the stale blocks end up wasted. 
They can further contribute to network centralization as huge 
mining parties, or mining pools, are less likely to get their 
blocks staled. Ethereum solves both issues by including stale 
blocks in the longest chain calculations. New blocks that 
include stales to their parents are offered part of the mining 
rewards, 12.5%, and the stale blocks get a 87.5%. However, 
they are not awarded transaction fees. Ancestor stale blocks 
are limited to k generations, where 2 < k < 7. SCs 
are used as sub-currencies or tokens representing assets in 
areas including financial applications, bounty programs, online 
voting, decentralized governance, and others. 

VI. Challenges 

Generally, most blockchains issues are concentrated in the 
following. 

A. Scalability 

As every node in the network processes every transaction, 
the Bitcoin main network currently has a 3 — 7 transactions per 
second (tps) throughput, while the Ethereum main network has 
a 15 tps throughput [15], on average. The current block size 
in Bitcoin is 1 MB, while Ethereum has a dynamic block size 
in gas price. As previously proposed [29], reparameterization 
of the block size and block production interval would increase 
the throughput of the network; it also leads to an increase 
in the block storage, bandwidth, and processing requirements. 
This sets a higher barrier for participating in the network 
and potentially risks its decentralization. Another approach 
taken by Ethereum is changing the consensus algorithm to 
PoS, which is -at the time of writing- a work under progress. 
As full-nodes maintain the whole blockchain, sharding was 
also proposed to increase the network throughput [30], [31], 
also planned by Ethereum. Sharding splits the network into 
partitions, allowing transaction processing in portions of the 
network rather than every participant node. 

Since block reparameterization is limited in increasing 
the network throughput, off-chain payment channels provide 
a theoretically unlimited throughput. In Bitcoin, off-chain 
channels required solving a transaction malleability problem 
in which transaction identifiers (TXID) can be tampered with, 
since digital signatures did not cover the whole transaction 



data. TXIDs were not stored in the blockchain for space con¬ 
siderations. The transactions; however, were valid. Malleability 
poses a problem in SCs as child transactions spend an output 
of its parent transaction. In this case, although the parent is 
valid and included in the blockchain; the children are invalid 
[32]. 

Off-chain channels allow transactions without including 
them directly in the blockchain. They were proposed to avoid 
transaction fees for micropayments [32]. To start a channel, 
a deposit and refund transactions are created with an amount 
to process. The refund one is only valid at a certain time in 
the future, which is the channel lifetime. While the channel 
is open, transactions would be performed without using the 
main network. A unidirectional payment channel uses two 
features, multi-signature outputs, and time-lock transactions. 
The first requires more than one party signature to spend, 
allowing more transaction control. The second can use either a 
timestamp or a certain block height to spend, allowing further 
transactions to be broadcast sooner, canceling later ones that 
spend the same transaction outputs, and effectively canceling 
the refund transaction. Bidirectional payment channels can 
be created using two unidirectional ones, an approach that 
is dependent on the amount deposited by each channel. To 
overcome such limitation, duplex micropayment channels [33] 
that allow resetting the unidirectional channels, and lightning 
channels [34] that are able to create bidirectional channels 
without time limitations were proposed. Both proposals allow 
two-side off-chain payment channels to be combined without 
trusted intermediaries. The lightning network is implemented 
for Bitcoin. A similar solution, the Raiden network, is devel¬ 
oped for Ethereum. 

Sidechains [35], an approach close to off-chains, allow 
for separate blockchains to exist, returning back to the main 
blockchain. Ethereum SCs allow for internal solutions for 
scalability, one of which is the Plasma framework [36]. It 
utilizes autonomous SCs to enable high state updates on top 
of the main network. A project that implements Plasma ideas 
in a decentralized exchange and a payment system is named 
OmiseGO [37]. 

B. Size 

Blockchain size also affects its scalability and puts a barrier 
for full-nodes network participation of a high disk space. At 
the time of writing, Bitcoin blockchain has a size of 280 GB, 
while Ethereum blockchain has a size of 438 GB [38]. Pruning 
is a mode that allows a compact storage for blocks. Once 
a block is received, the validated transactions are no more 
needed, resulting in pruned blocks. The disadvantage is that 
the result cannot serve other peers that require the original 
blocks. This constructs a trade-off between disk space usage 
and historical block accessibility in the network. As mentioned 
in Section IV, light clients, or nodes, are also used to overcome 
the storage requirements. They allow transaction validation by 
querying full-nodes for proofs of UTXOs. It is notable that the 
sharding solution also affects the blockchain size. 

C. Forking 

While forking is a property that can be used in favor of 
a distributed ledger, it can also be considered a challenge. 


Forking can be caused by propagation delays, attacks, or 
changes in the network protocol. Propagation forks are typ¬ 
ically handled using the longest chain rule. As eventually new 
blocks are propagated, they would lead to a single longest 
chain and restore consensus, leaving orphaned forks behind. 
There are two types of software forks, soft and hard forks. 
Soft forks allow for software updates that might be more 
strict but compatible with the existing chains. In this case, 
the new changes are also accepted by the previous versions, 
and the participants are not required to upgrade. Hard forks 
provide changes that are not compatible and hence deploying 
them would result in a new chain. The other one will not 
cease to exist if some nodes continued operating it; that is, the 
nodes are potentially split between the chains. Hard forks are 
also used in case of attacks to select a historical block for a 
roll back. In such cases, peers can decide between the chains 
to support and both may continue operating. The split forks 
are primarily subject to transaction replay attacks. In PoW, 
the block production time ensures a delay time to resolve 
propagation forks. As previously mentioned, considering the 
stale blocks in the chain decreases propagation forks and 
potentially provides more network participation incentive. 


D. Privacy 

In Bitcoin and Ethereum provide pseudonymity since the 
transactions between addresses are publicly available, but the 
identity of senders is not. Hence the public address must be 
kept separate from a human identity. Generating a new address 
for each transaction is advised as otherwise, comparison-based 
attacks on signatures can be performed [14]. This also assures 
that no chain of blocks is previously prepared ahead of time. 
However, as the internet infrastructure is not anonymous, the 
transactions are still linkable using multi-input transactions to 
point multiple addresses to the same owner. They are also 
traceable since on the network layer, the IP addresses can be 
traced. Transaction mixing can provide a primitive to decrease 
linkability between the addresses. While early versions of 
mixing protocols are vulnerable to sybil attacks; a newer 
proposal [39] provides a sybil-resistant protocol. 

As the privacy can be divided into four distinct concerns, 
namely 1) the transaction origin, 2) its destination, 3) its 
amount, and 4) the network layer, there are projects ded¬ 
icated to solving these issues using different cryptographic 
techniques. Zcash, previously called ZeroCash [40], uses zero- 
knowledge Succinct Non-interactive ARguments of Knowl¬ 
edge (zk-SNARKs) [41], [42], to provide an anonymous 
scheme for transactions where they can be encrypted on the 
blockchains, but also easily verifiable without revealing their 
information, and without requiring further interactions beyond 
the sender’s message. Other projects like Monero [43], use 
ring signatures to obfuscate the sender’s address. It also uses 
stealth addresses to obfuscate the receiver’s address. Using 
Ring CT, an improved ring signatures scheme [44], or Mul¬ 
tilayered Linkable Spontaneous Anonymous Group signatures 
(MLSAG), the amount of transfer is also hidden. For the IP 
network layer, Monero offers Kovri [45], a private overlay 
network that provides end-to-end communication encryption. 



E. Resource Utilization 

In Bitcoin, the stale blocks are disregarded, and the re¬ 
sources put in them are wasted. Generally, as PoW mining 
process consumes high electricity and computation power, this 
raises questions about its energy efficiency, one reason for 
switching to other consensus protocols. 

F. Nondeterministic Consensus 

Non-byzantine consensus mechanisms we mentioned are 
nondeterministic, providing no guarantee of a final state for 
the blockchain. This issue is also referred to as finality. Even 
though a transaction is confirmed in a block, the block can be 
rolled back if a longer chain appeared and considered to be the 
main chain. Selfish mining [46] refer to the idea that it might 
be more profitable for parties to mine on their own fork that is 
kept private, causing an intentional fork later when revealing 
it. The transactions confirmed in an orphaned fork are rolled 
back after restoring consensus. To counter such forks, waiting 
for six confirmations is considered probabilistically safe for a 
transaction to be assumed final in Bitcoin. 

G. Quantum Computation 

Widely used cryptographic methods rely on the assumption 
of being hard problems for computation systems. According 
to the NIST [47], on the advent of powerful quantum com¬ 
puters, public key encryption assumptions will be impotent. 
Shor’s algorithm offers rapid computations to two widely used 
mathematical problems, namely discrete logarithms and prime 
factorization [48], used in digital signatures. Also, Grover’s 
algorithm is perceived to require 6(y/N) operations to solve 
a 9(N) search problem [48]. Bitcoin and other blockchain 
systems use an adjustable difficulty, mentioned in Section IV. 
It is designed to adapt to increased computation power that 
can be posed by quantum computations. Cryptographic hash 
functions can be protected against Grover’s algorithm [49] 
by doubling their digest sizes, and post-quantum signature 
schemes [50] can counter Shor’s algorithm advantage. 

VII. Alternative Data Structures 

DAGs are used as a distributed graph structure where each 
node represents a piece of information. As Ethereum uses 
DAGs in PoW mining, they were also proposed to increase 
the throughput in blockchain systems by modeling blocks as 
their nodes [51]. They were later applied as an alternative to 
blockchains, storing transactions as their nodes. 

A. The Block-Lattice 

As described in Nano project [9], block-lattice is a DAG 
structure formed of accounts. Each account, controlled by its 
private key, has its own blockchain, see Figure 2. All account 
blockchains are replicated to all peers in the network. PoW 
is used inside each account to create new blocks using the 
hash of its previous block, as an anti-spam mechanism, but 
is not used to achieve distributed consensus. For the first 
block creation, the account’s public key is used to replace the 
previous block hash. Each account has an open block, and its 
balance is represented by the send and receive blocks. The 
send blocks are used to make a certain amount receivable by 
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Fig. 2. A block-lattice DAG structure with 3 accounts or blockchains. 
The solid arrows refer to the hash pointers to previous blocks in the same 
blockchain, and the dashed arrows refer to transactions across blockchains. 

another account. The receiver account creates a receive block 
to increase its balance by the send amount. An open block is 
as a receive block in that its hash is to be accompanied by a 
send block, which means there must be a balance sent to an 
address in order to open an account and create its first block. 
Transactions are created by using an account’s private key to 
sign a block that is published to the whole network. For a 
more general purpose, there can be any type of transactions 
for sending arbitrary data. Peers can validate and accept blocks, 
propagating the new account states. 

Wallet creation for Nano includes the generation of a 
random seed value. Each wallet can hold an arbitrary number 
of accounts identified by their indices. As blocks in an account 
are signed by its owner, forks result from bad programming 
or attacks. Nano includes a voting mechanism in case of forks 
in which there exist more than one propagated state for an 
account. The voting is according to a weight based on each 
account balance. After four-round accumulations, a winning 
block is announced. An account balance can be delegated 
by assigning a representative. Representatives are included in 
the open block of an account but can be changed through 
publishing a change transaction as a change block. 

B. Hashgraph 

Hashgraph is a DAG connected by cryptographic hash 
pointers. Each node points to two parents, the self-parent which 
it extends, and another parent, see Figure 3. The parents refer 
to the notation of an ordering. Particularly, each graph section 
is a line of graph nodes representing the order of synchro¬ 
nization. The line grows up with each node hash pointing to 
both, its parent as mentioned, and another parent that originally 
created it. Collectively, a set of lines represent the whole graph. 
A line may represent an account or a participant in the network. 
Each node in a line may hold any sort of payload, like a set of 
transactions, and their order is agreed upon using a consensus 
algorithm. 

The first graph node in a line typically contains some 
initialization data. Each graph node is digitally signed by 
















Fig. 3. The Hashgraph structure. Participants represent lines A, B, C, and D. 
The solid arrows refer to self-parents, and the dashed arrows refer to creator 
parents. The topological order is perceived as time flows upwards. 

its creator to protect its content. The signatures may include 
the timestamp for which the the graph node is synchronized. 
Hashgraph is used in conjunction with a protocol that utilizes 
its data structure. The network participants run a gossip 
protocol in which they call each other at random. For a typical 
gossip protocol, there is no need to store the graph. However, 
hashgraph provides an extension for the idea by introducing 
gossip about gossip, in which each participant does store the 
graph. The key idea is in the two hashes stored at each node 
in the graph, as they represent the history of gossip about 
gossip. Since the history is stored by each participant, there 
is no need for further communication about consensus. Each 
participant calculates locally what another participant would 
send, an idea referred to as virtual voting. The algorithm is 
asynchronous BFT in the strong definition. Its proof assumes 
for n nodes, n > 1, that more than 2n/3 of the participant 
nodes are honest, and less than n/3 are not. The consensus 
is achieved with probability one. It works in rounds of virtual 
voting until convergence is achieved with probability that in¬ 
creases exponentially each round. To prevent non-termination, 
a constant periodic coin rounds are used, and a decision is 
pseudo-randomly reached between the participants in the last 
round. 

C. The Tangle 

In IOTA, a project aimed to be the cryptocurrency of the 
Internet of Things (IoT), the tangle is the ledger used for 
storing transactions. Each graph node represents a transaction 
and each edge represents a confirmation of another transaction, 
see Figure 4. In the tangle, each new transaction is required 
to approve k previous transactions chosen at random, or two 
transaction in IOTA (k = 2), having k edges pointing to 
their graph nodes. Between two nodes, the indirect path is 
considered as an implicit approval. The new graph nodes, or 
the tips, wait for newer ones to be approved. The first or 
genesis graph node is approved directly or indirectly by all 
other nodes. A k > 2 tangle connection or approval is also 
possible. Each transaction is assigned a weight proportional 



Fig. 4. The tangle structure. The black node is the genesis node, and the 
gray nodes are the tips. The graph is perceived to grow from left to right. 

to the amount of work invested into it. The work is to find a 
nonce that is when hashed with the transaction data, it takes 
a defined form. This is intended to prevent denial of service 
attacks. There are also other properties required for approval 
of transactions in IOTA. The cumulative weight is the sum 
of the weight of a transaction and all transactions directly or 
indirectly approving it. The height represents the longest path 
to the genesis; while the depth represents the length to some 
tip. The score of a transaction is the sum of its weight and 
all weights of the transactions approved by it. The height and 
score are used for approval of k new transactions if they are 
not chosen at random. 

In IOTA, double-spending is prevented directly by refusing 
conflicting transactions and indirectly by refusing transactions 
that approved conflicting ones. As in Bitcoin and Ethereum, 
confidence level increases probabilistically with time as the 
cumulative weight of a transaction increases. 

VIII. Conclusion 

The claim to immutability in blockchains is backed by the 
guarantees of their cryptographic primitives. Challenges in net¬ 
work throughput, data structure storage, achieving distributed 
consensus deterministically, forking, privacy, power consump¬ 
tion, and quantum advances, resulted in new mechanisms and 
alternative structures. All such structures use hash pointers to 
refer to blocks or graph nodes built upon each other and can 
be stored and validated in a distributed manner. Originally, 
blocks used hash pointers to form blockchains. Then, hash 
pointers were used to model blocks as graph nodes in DAGs. 
Afterwards, the graph nodes were used to directly store and 
represent transactions, also using hash pointers. Based on 
that, one could imagine any data structure using the same 
construction. 
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